Modeling languages may be used as meta-languages to describe and execute underlying processes, such as business processes. For example, process modeling languages allow an enterprise to describe tasks of a process, and to automate performance of those tasks in a desired order to achieve a desired result. For instance, the enterprise may implement a number of business software applications, and process modeling may allow coordination of functionalities of these applications, including communications (e.g., messages) between the applications, to achieve a desired result. Further, such process modeling generally relies on language that is common to, and/or interoperable with, many types of software applications and/or development platforms. As a result, process modeling may be used to provide integration of business applications both within and across enterprise organizations.
Thus, such modeling languages allow a flow of activities or tasks to be graphically captured and executed, thereby enabling resources responsible for the activities to be coordinated efficiently and effectively. The flow of work in a process is captured through routing (e.g., control flow) constructs, which allow the tasks in the process to be arranged into the required execution order through sequencing, choices (e.g., decision points allowing alternative branches), parallelism (e.g., tasks running in different branches which execute concurrently), iteration (e.g., looping in branches) and synchronization (e.g., the coming together of different branches).
In the context of such processes, as just referenced, it may occur that a number of tasks or activities may be executed in parallel. Further, in real-world scenarios, it may occur that a selection or execution of subsequent tasks may depend on a current or final outcome(s) of some or all of the executing, parallel tasks. For example, a business process model may include multiple tasks, executing in parallel, that are each related to loan requests for obtaining loan approval from one or more of a number of lenders. Subsequent tasks may thus hinge on a current or final outcome of some or all of these loan requests. For example, as loan requests are transmitted, it may occur that some loan requests may never be answered, or may result in loan approvals for loans have extremely high or extremely low interest rate(s), or may have some other desirable or undesirable result. Consequently, for example, subsequent tasks may include aborting the loan process for lack of desirable loan options after some period of time, or may include selecting some defined subset of the resulting loan approvals, or may include initiating new loan requests.
Frequently, it may be difficult or problematic to express and encompass such parallel tasks, and pluralities of subsequent tasks (and criteria for decisions therebetween), in a manner that is executable as a process model. For example, even when such parallel tasks are combined or synchronized at a defined point in the process model, the result may be simply that a pre-specified, static number of the parallel tasks (for example, 2 out of a possible 4 tasks) cause execution of a subsequent task. Such approaches, however, may be limited in applicability and usefulness. For example, a different or dynamic number of parallel tasks may be implemented, or a different or dynamic number of the implemented tasks may optimally be required before synchronization occurs. For example, in the example just given, it may be that 4 tasks anticipated at design-time may become 5 or more tasks at run-time, and/or it may occur that instead of 2 tasks being required for activation, a user of the process model may wish to cause synchronization after a single one of the parallel tasks executes, or after 3 or more execute, or after some changing or dynamic number(s) execute. Thus, in these and other cases, process models may fail or be limited in their goal of expressing real-world processes in a flexible, repeatable, computer-executable manner.